Skip to content

Refactor (packages/app/src/components/dialog-custom-provider-form.ts): Function with high complexity - #64

Open
MidnightEmoClub wants to merge 3 commits into
CMU-17313Q:mainfrom
MidnightEmoClub:validation-helpers
Open

Refactor (packages/app/src/components/dialog-custom-provider-form.ts): Function with high complexity#64
MidnightEmoClub wants to merge 3 commits into
CMU-17313Q:mainfrom
MidnightEmoClub:validation-helpers

Conversation

@MidnightEmoClub

@MidnightEmoClub MidnightEmoClub commented Sep 4, 2026

Copy link
Copy Markdown

P1B: Starter Task: Refactoring PR

Use this pull request template to briefly answer the questions below in one to two sentences each.
Feel free to delete this text at the top after filling out the template.

1. Issue

Link to the associated GitHub issue: #14

Full path to the refactored file:
packages/app/src/components/dialog-custom-provider-form.ts

What do you think this file does?
Validates the "Add custom provider" dialog form and builds the provider config object when the form is valid.

What is the scope of your refactoring within that file?
validateCustomProvider()

Which Qlty‑reported issue did you address?
Function with high complexity (count = 31) in validateCustomProvider()

2. Refactoring

How did the specific issue you chose impact the codebase’s maintainability?
validateCustomProvider() was a ~100-line monolith that contains trimming, parsing, and validation of three separate domains (top-level fields, model rows, header rows), making the logic hard to read, test, and reuse.

What changes did you make to resolve the issue?
I extracted the three domain-specific logics into focused helpers — validateBase(), validateModels(), and validateHeaders(), so the main function became a short composition of three calls

How do your changes improve maintainability? Did you consider alternatives?
Each helper now focuses on one validation domain with a clear contract (independently readable, testable, and reusable), while the main function is pure composition with no duplicated trim/config logic.

I considered writing a universal validation function for both the models and headers. However, they have slightly different validation logic (empty row handling, case-sensitivity, and field naming), so it would be overcomplicated to implement validation logic in one function.

3. Validation

How did you validate that the change is correct?

  • bun typecheck for syntax check
image
  • bunx oxlint packages/app/src/components/dialog-custom-provider-form.ts for lint test (no bun lint because it seems that there are other files in the repo that could not pass the lint test)
image
  • bun test ./src/components/dialog-custom-provider.test.ts Unit test for this module
image

Attach a screenshot of the test coverage showing the lines were executed by the tests.
image

Attach a screenshot showing the tests that cover the change passing during CI
image

Attach a screenshot of qlty smells --no-snippets <full/path/to/file.ts> showing fewer reported issues after the changes.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant